Typically, software is released in successive versions. Each successive version makes changes that either correct errors in previous versions or add additional functionality. One area of concern in versioning software is maintaining compatibility with prior versions. For example, if a previous version has been released with a particular class definition, a successive version with a different definition of that class can incur difficulties in loading data defined using the previous version.
In a specific example, if a user defines a Java class that is serializable, but does not define a Serial Version ID, this class cannot be loaded in the next version of the Java Virtual Machine (JVM) if the class has been changed between the JVM versions. One possible approach to solving this problem would be to change the source class to declare the serial version identifier.
This solution would not be available, however, in situations where a portion of the software, such as a class definition, for example, has been exposed to the user to permit user modification of the class. In such cases, the developer may confront incompatibility issues if a later version attempts to modify the class. In one typical scenario, the developer would write a first version. Another party modifies the first version to make a second version. During loading, for example, the loader finds the second version instead of first version and raises an exception.
Practically speaking, the developer may not have access to classes previously released and then modified, eliminating reversioning of such classes as an option. If the developer is no longer able to access the code, the developer could not change the first version class. Instead, the developer would need to work with the second version.
However, none of these approaches enables working with data stored according to previously used versions of classes.